Implementing and coordinating configuration of protocols

ABSTRACT

The present invention employs a method for coordinating communication of protocols within Access Terminals in order for the Access Terminals to successfully and efficiently communicate with the protocols within an Access Network. The method of the present invention can be used in conjunction with the current IS-856 standard. After receiving an indication of required configuration from one or more of the answering protocols, the SCP issues a configuration command to all of the answering protocols in the AT. If the answering protocol determines that it needs to reconfigure any of its parameters, it accepts the configuration command and notifies the SCP that it has accepted the configuration command. Alternatively, if the answering protocol determines that it does not need to reconfigure any of its parameters, it rejects the configuration command and notifies the SCP that it has rejected its configuration command. Communication between the Access Terminal and the Access Network then resumes.

BACKGROUND OF THE INVENTION

[0001] The present invention relates generally to the communication ofaccess terminals with an IS-856 network on which the terminals arelocated, and more specifically to the coordination of the communicationof the IS-856 protocols within the access terminals.

RELATED ART

[0002] In a typical network utilizing the IS-856 protocol standard, anetwork access terminal (AT) connected to a network (AN) routinelyrequires a change to its existing state. For example, on a networkutilizing the IS-856 standard, an access terminal such as a mobiletelephone has a dynamic address, which serves as its unique identifier(that is, as the telephone moves around the country, its assignedaddress changes accordingly). For instance, a mobile telephone in NewYork could have the address HDA412. Upon being transferred by its userto California, however, the mobile telephone's address might change toCDB139, for example.

[0003] As a result of this change of address, the AT may have to changeits existing control channel cycle. If the AT was previously on channel5 but is now required to be on channel 7, then a particular IS-856protocol requiring such a change (that is, an answering protocol in theAT) must detect that the change needs to occur.

[0004] To accomplish such a change in the AT, the AT and the AN mustcommunicate with each other. In particular, a protocol of the AT knownas the Session Configuration Protocol (SCP) (defined in the IS-856standard as a protocol responsible for coordinating and managing theconfiguration of other protocols), must communicate with itscorresponding peer on the AN. Likewise, other non-SCP protocols of theAT requiring change must communicate with their corresponding peer onthe AN.

[0005] While the IS-856 standard defines a specific time at which the ATis allowed to “speak” and a specific time at which the AN is allowed to“speak”, prior to the development of the present invention, there was nodefined standard for how the AT requiring a protocol change coordinatedits protocols to relay its need to change the existing status of one ormore of its protocols (for example, changing of a control channel) tothe AN. Similarly, before the present invention, there was no definedstandard for the SCP of the AT to inform the protocol requiring changethat it was allowed to execute the change. Also, before the presentinvention, there was no defined interface for SCP to tell the protocolrequiring change of the appropriate time for the change to take effect.Additionally, prior to the present invention, there was no specifiedmethod for maintaining a session when power is lost and then restored.

[0006] Therefore, what is needed is a method which defines a standard bywhich an AT requiring configuration change coordinates its protocols torelay its need to change the existing configuration status of one ormore of its protocols to the AN. The method should also define astandard by which the SCP of the AT informs the protocol requiring achange in its status that it is allowed to execute the change.

SUMMARY OF THE INVENTION

[0007] The present invention meets the above-referenced needs byproviding a method which defines a standard by which the AT requiring aprotocol change coordinates its protocols to relay its need to changethe existing configuration status of one or more of its protocols (forexample, changing of a control channel) to the AN.

[0008] Upon initialization, SCP reads its last known status fromnon-volatile memory to determine if the session related data is valid.If the data is valid, SCP reads its own session related information.Then, all answering protocols refer to SCP to determine whether theyshould get previously negotiated data from non-volatile memory.

[0009] The present invention employs the use of commands and indicationsto facilitate the coordination of communication between the protocols ofthe AT. The AT contains a group of protocols wherein each member of thegroup is responsible for performing some function of the AT. Eachprotocol in this group is referred to as an “answering protocol.” The ATalso contains a protocol that is responsible for managing the otherprotocols, the SCP protocol. After detecting a need to configure, one ormore answering protocols send an indication to the SCP, notifying theSCP that at least one of the answering protocol's attributes requiresreconfiguration. Upon receiving this indication from one of theanswering protocols, the SCP issues a configuration command to all ofthe answering protocols in the AT.

[0010] The configuration command is transmitted to all of the answeringprotocols in the AT to poll them in an attempt to discover whether theyhave a need to alter their current configuration. After an answeringprotocol receives the configuration command, it checks its currentconfiguration status and determines whether it needs to alter it (thatis, the answering protocol determines whether it needs to performreconfiguration). If the answering protocol determines that it needs toreconfigure any parameters that can be changed by configuration, itaccepts the configuration command and notifies the SCP that it hasaccepted the configuration command. Alternatively, if the answeringprotocol determines that it does not need to reconfigure any of itsparameters, it rejects the configuration command and notifies the SCPthat it has rejected its configuration command.

[0011] If all answering protocols reject the configuration command, SCPproceeds as if all configuration complete indications have beenreceived. If at least one answering protocol accepts the configurationcommand, however, it eventually transmits an indication to the SCP thatit has completed configuration (that is, a configuration completeindication) or an indication that the configuration attempt failed (thatis, a failed protocol configuration indication).

[0012] If the Session Management Protocol (SMP) receives the failedprotocol configuration indication, the session is closed. It the SCPreceives the configuration complete indication from all protocols thataccepted the configuration command, the SCP transmits a configurationcomplete message to its corresponding peer in the network, notifying itspeer that configuration on the part of the AT has been completed.

[0013] When SCP receives the configuration complete message, it returnsthe reconfigured indication. All answering protocols use this indicationto begin the data agreed upon in the most recent round of negotiation.

[0014] The present invention also provides a method by which entrapmentwithin an AT initiated state is prevented. The concern is that a trafficchannel loss or network acquisition loss will occur during the ATinitiated state and communication will be trapped in the AT initiatedstate. The present invention addresses this concern and preventsentrapment in the AT initiated state via the maintenance of timersdesigned to expire in a specified amount of time if the network does notrespond with a response message. In addition, SCP will determine ifconfiguration messages can be resent. If so, the answering protocolconfiguration commands will be recalled. The answering protocol willstop a running timer if it is called.

BRIEF DESCRIPTION OF THE FIGURES

[0015] The features and advantages of the present invention will becomemore apparent from the detailed description set forth below when takenin conjunction with the drawings in which like reference numbersindicate identical or functionally similar elements. Additionally, theleft-most digit of a reference number identifies the drawing in whichthe reference number first appears.

[0016]FIG. 1 is a state diagram depicting the relevant state transitionsbetween an AT and an AN on which the AT is located.

[0017]FIG. 2 is a block diagram representing the two protocolscontrolled by the Session Management Protocol.

[0018]FIG. 3 is a flowchart representing the general operational flowfor a method for initializing an AT.

[0019]FIG. 4A is a flowchart representing the general operational flowfor a method for changing an existing condition in an AT from theperspective of the SCP in the AT.

[0020]FIG. 4B is a flowchart depicting continuing flow of FIG. 4A.

[0021]FIG. 5A is a flowchart representing the general operational flowfor a method for changing an existing condition in an AT from theperspective of an answering protocol in the AT.

[0022]FIG. 5B is a flowchart depicting continuing flow of FIG. 5A.

[0023]FIG. 6 is a block diagram of an apparatus implementing protocolmanagement.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0024]FIG. 1 shows the relevant state transitions involved in thecommunication sequence between the AT and the AN. The figure illustratesthe coordination of times at which protocols in the AT are allowed tospeak, and the times at which protocols in the AN are allowed to speak.It should be noted that the communication between the AN and an AT iscurrently part of the IS-856 standard. However, the relevant statetransitions depicted in FIG. 1 are shown to facilitate the understandingof the practical utility of the present invention (that is, to show howthe present invention can be used in conjunction with the current IS-856standard).

[0025] Communication is inactive, represented by inactive state 110,when there is not a current session and no configuration. A session is ashared state between the AT and the AN. It stores the protocols andconfigurations that were negotiated and used for communication betweenthe AT and the AN. A session must be opened for communication to occurbetween the AT and the AN. Communication changes from inactive state 110to open state 120 upon obtaining a session. No configuration isoccurring, however, in open state 120. Thus, no protocol in the AT istransmitting a request message to its corresponding peer on the AN torequest configuration. (That is, no protocol in the AT is transmitting arequest message to an answering protocol in the AN).

[0026] When at least one protocol in the AT transmits a request message,communication changes to access terminal (AT) initiated state 130. Forinstance, referring to the above-referenced example of an AT protocolrequiring a change of its control channel, the SCP of the AT must firstreceive notification from the answering protocol of the AT responsiblefor the required configuration change. Such notification informs the SCPof the AT that the control channel of the AT requires change. Uponreceipt of the notification from the answering protocol, the SCP of theAT may transmit a configuration request message to the SCP in thenetwork, configuring its own parameters. If this is necessary, SCP sendsthe configure command to all answering protocols. Upon transmission ofthe configuration request message from any protocol in the AT to itspeer in the AN, communication changes from open state 120 to accessterminal initiated state 130.

[0027] The AT speaks in the Access Terminal Initiated state 130. Forinstance, referring again to the above-referenced example, in thepresent invention, the SCP in the AT transmits a command to the protocolresponsible for changing the control channel (that is, one of theanswering protocols). Upon completion of its configuration, theanswering protocol transmits an indication to the SCP in the ATindicating that it has completed configuration. Likewise, all answeringprotocols (that is, other protocols in the AT responsible for aparticular change in the status of the AT) transmit a completedconfiguration indication to the SCP in the AT. Communication changesfrom Access Terminal Initiated state 130 to Access Network Initiatedstate 140 after SCP in the AT receives all indications of completedconfiguration from the answering protocols of the AT and sends theconfiguration complete message. The SCP in the AT then transmitsnotification to the SCP on the AN indicating that all protocols in theAT have completed their configuration (that is, the SCP on the ANtransmits a configuration complete message to the SCP in the AT).

[0028] In the AN initiated state, any protocol in the AN is allowed tosend Configuration Request Messages to its peer in the AT. When the ANdetermines that it has finished configuration, the SCP on the ANtransmits a configuration complete message back to the SCP in the AT.The configuration complete message transmitted from the SCP on the ANserves as notification to the SCP in the AT that the AN has completedits part of the configuration. The configuration complete messageindicates the transition to the AT initiated state.

[0029] For instance, continuing with the above-referenced example of thechange of an AT's control channel, transmission of the configurationcomplete message from the SCP on the AN to the SCP in the AT indicatesthat all of the necessary configuration required for changing thecontrol channel of the AT has been completed on the AN side, and thecontrol channel of the AT can now be changed and take effect upon returnto the inactive state.

[0030] Referring now to FIG. 2, the Session Layer of the protocol stackfor the IS-856 standard comprises the Session Management Protocol (SMP)210, the Address Management Protocol (AMP) 220, and the SessionConfiguration Protocol (SCP) 230.

[0031] The Session Layer of the stack is responsible for managing thesessions between cooperating applications that are transferring data toeach other. SMP 210 is responsible for managing the activation of theother Session Layer protocols (that is, the SCP and the AMP) and theclosure of the session. AMP 220 is responsible for maintaining addressinformation. SCP 230 is responsible for handling protocol subtypes andmaintaining the status of the current session, status during initiation,and coordination of answering protocols during configuration.

[0032] It should be noted that FIG. 2 is only presented for the purposeof providing the reader with insight as to where the focus lies in thepresent invention. Such insight is necessary in understanding how thepresent invention can be used in conjunction with the current IS-856standard. All protocols depicted in FIG. 2 are currently part of theIS-856 standard.

[0033] Referring to FIG. 3, a flowchart depicting a routine forinitializing an access terminal 302 is shown. Control begins at step305. In step 305, the SCP of the AT is initialized. Step 305 comprisesfour steps: step 310, step 315, step 320, and step 325.

[0034] For each session, all protocols maintain a group of variables forall session-related parameters. For instance, the SCP maintains a“current” variable indicating the current used subtypes for the session,and a “negotiated” variable indicating the values that were mostrecently negotiated but not yet used during the particular session.Similarly, the SCP maintains a “previous” variable indicating the valuesused in the previous session. A “default” variable is maintained andused when a value for a configurable attribute is requested from the ANand rejected. For the answering protocols that will send a configurationrequest message, a “desired” variable may be maintained. It includes theoptimal values for all parameters and is set upon initialization andchanged whenever related system attributes change.

[0035] Finally, the protocols contain a regional structure containingdata regarding a currently negotiated configuration parameter. Forinstance, the structure could contain a transaction ID, sent attributeIDs, and a boolean flag to indicate whether the Signaling Link Protocolhas received the acknowledgment for the transmitted configurationrequest message transmitted by a protocol in the AT. In one embodiment,this variable can also contain a list of data that has been sent. Aftera transmitting protocol of the AT obtains a configuration responsemessage from the AN, it can use the data stored in this structure tocompare with the data received in the configuration response messagefrom the AN. Thus, only protocols which are capable of sending aconfiguration request message would have this structure.

[0036] When the AT is initially powered, the negotiated, current, andprevious values for the variables of the session-related parameters mustsomehow be determined.

[0037] Referring back to FIG. 3, in step 310, the first step of theinitialization of the SCP of the AT, the session status is read fromnon-volatile memory. To accomplish this, a function is called todetermine how the values for the variables of the varioussession-related parameters are to be determined.

[0038] In step 315, a determination is made as to whether sessionconfiguration data will be read from non-volatile memory.

[0039] The above-referenced function can return a value of true orfalse. A returned value of false indicates that the values for thevariables are not to be read from non-volatile memory. In this case, instep 320, default values are assigned to the above-referenced current,negotiated, and default variables.

[0040] If the above-referenced function returns a value of true, in step325, the values for the variables are read from a non-volatile memoryand are systematically assigned to the appropriate variables. Forinstance, the current, negotiated, and default variables are allprovided with values read from the non-volatile memory.

[0041] Step 325 marks the end of the initialization process of the SCPof the AT.

[0042] In step 330, the non-SCP protocols of the AT are initialized.Step 330 is comprised of steps 335, 340, 345, and 350. For each session,each answering protocol maintains the above-referenced group ofvariables.

[0043] When the AT is initially powered, the negotiated, current, andprevious values for the variables of all of the non-SCP protocols (thatis, the answering protocols) must somehow be determined, just as theywere for the SCP in the AT. In step 335, the first step of theinitialization process of the answering protocols, a determination ismade as to whether session configuration data will be read fromnon-volatile memory. In step 335, the session status need not be readagain from non-volatile memory. Rather, the answering protocol queriesthe SCP of the AT to determine whether it is to use the configurationdata in non-volatile memory.

[0044] If the above-referenced function returned a value of false, instep 340, the values for the variables are assigned default values.

[0045] Alternatively, the function may return a value of false,indicating that the values for the variables are not to be read fromnon-volatile memory. In this situation, in step 345, the values for thevariables are read from the non-volatile memory and are systematicallyassigned to the appropriate variables. In other words, the current,negotiated, and default variables are all provided with values read fromthe non-volatile memory.

[0046] In step 350, a determination is made as to whether all answeringprotocols have been initialized. If not, the next protocol isinitialized, which means steps 335-345 are repeated for that particularprotocol. These steps are repeated for every protocol which needs to beinitialized.

[0047] When all protocols have been initialized, control ends at step355. At this point, the SCP of the AT and all answering protocols havebeen initialized.

[0048] Referring now to FIG. 4A, a routine for changing an existingcondition (that is, changing an existing configuration status) in anaccess terminal is shown from the perspective of the SCP in the AT.

[0049] Control begins with step 405. In step 405, an answering protocoldetects a need to change an existing condition in the AT. For instance,the protocol responsible for changing the control channel of the ATdetects that it needs to change the AT's control channel.

[0050] After the protocol detects its need to change, in step 410, theSCP of the AT receives a configuration request indication from theanswering protocol.

[0051] Alternatively, the need to change an existing condition in the ATmay be triggered, in step 412, when SCP receives a configuration startmessage or, in step 413, when a traffic channel is lost. These two stepsprovide alternative paths to step 415.

[0052] In step 415, the SCP waits until requirements are met beforebeginning configuration. A requirement for beginning configuration mayinclude acquisition of a network. When this condition is met, the SCP ofthe AT begins configuration. In step 416, a check is performed to see ifSCP needs to reconfigure.

[0053] After the SCP of the AT receives notice that reconfiguration hasbeen requested, in step 420, the protocol sends a configuration requestmessage to its corresponding peer in the network. The SCP contains aresponse timer which expires if its corresponding peer in the networkdoes not transmit a configuration response message within a specifiedamount of time. Further, the SCP contains an awaiting acknowledgmentflag which is used to notify it of successful delivery of itsconfiguration request message to its corresponding peer in the network.The flag is initially set to true, indicating that it is currentlyawaiting acknowledgment of successful delivery of its configurationrequest message.

[0054] If the timer expires, the Session Management Protocol (SMP) ofthe AT transmits a session closed message to its corresponding peer onthe AN. SCP stops the configuration response timer, and indicates thatit is no longer awaiting notification of the successful delivery of itsconfiguration request message by setting its awaiting acknowledgmentflag to false. All protocol data from the “current” variable is thenplaced into the “previous” variable.

[0055] In step 425, the SCP of the AT receives a configuration responsemessage from its corresponding peer in the AN. SCP can then go back tostep 420 if it determines that another configuration request message isneeded or it can proceed to step 430 if it is done.

[0056] In step 430, when it is determined that SCP does not need toreconfigure, the SCP of the AT sends a configuration command to all ofthe answering protocols in the AT, instructing them to begin thenecessary configuration to carry out the required changes in theirstatuses. In certain situations, an answering protocol in the AT willnot accept the SCP's configure command. For instance, if the answeringprotocol determines that it does not have a need to change its existingconfiguration, it rejects the SCP's configuration command.

[0057] In step 435, the SCP of the AT determines whether any of theanswering protocols to which it transmitted the configuration commandactually accepted the command. If the SCP received a boolean value offalse, or ‘No’, from all of the answering protocols, it therebydetermines that none of the answering protocols accepted the command(that is, all answering protocols rejected the configuration command).The SCP next checks to see if a configuration start message wasreceived, step 437. If not, the SCP of the AT transmits a configurationcomplete message to its corresponding peer on the AN and noconfiguration occurs. Flow then stops at step 440. If a configurationstart message is received, control continues in FIG. 4B with the letterB.

[0058] Alternatively, if the SCP of the AT receives a boolean value oftrue from the answering protocol, it thereby determines that theanswering protocol accepted the command. Control then resumes with step445.

[0059] Next, in step 445, the answering protocol determines whether itscommunication with its peer on the network was successful.

[0060] If communication was unsuccessful, then in step 450, the SCP ofthe AT receives a failed protocol negotiation indication from theanswering protocol.

[0061] In step 455, the SMP of the AT closes the session, and controlthen ends at step 460.

[0062] Alternatively, if communication was successful, then controlresumes in FIG. 4B with letter A. In step 465, the SCP of the ATreceives a configuration complete indication from the answeringprotocol.

[0063] Upon completion of the configuration and relay of this event backto the SCP of the AT (that is, upon receiving from the answeringprotocol the configuration complete indication), in step 470, the SCP ofthe AT transmits a configuration complete message to its correspondingpeer on the network (that is, the SCP on the network), thereby informingits peer that configuration has been completed on the AT side. Thiscorresponds with the state transition from 120 to 130.

[0064] In step 475, the SCP of the AT receives a response from the SCPon the AN indicating that it has completed its part of the requiredconfiguration.

[0065] In step 480, the SCP of the AT transmits an indication to theanswering protocol informing the answering protocol that all necessaryconfiguration has been completed (for example, the necessaryconfiguration for the change in the AT's control channel has beencompleted). Alternatively, a previous session opened indication may besent. Thus, the value of the negotiated or previous variables are copiedto the current variable accordingly to reflect the new configuration.

[0066] Finally, control ends with step 485.

[0067]FIG. 5 shows a routine for changing an existing condition (thatis, changing an existing status) in an AT from the perspective of theanswering protocol 500.

[0068] Control begins with step 505. In step 505, an external eventindicates that an existing condition needs to be altered (for example,the control channel of the AT needs to be changed).

[0069] In step 510, the answering protocol transmits a configurationrequest indication to the SCP of the AT, informing the AT of theexternal event triggering a need to reconfigure the session.

[0070] In step 515, the answering protocol receives the configurationcommand from the SCP of the AT, instructing it to begin configuration.The routine can also be started here, for instance if a differentanswering protocol sent the indication.

[0071] In step 520, the answering protocol determines if the instructedconfiguration is necessary. It is possible that system configurationchanged since the configuration request indication was sent soconfiguration is no longer needed.

[0072] In step 525, if the answering protocol determines that theconfiguration is not necessary, it returns the boolean value of false tothe SCP of the AT, thereby communicating its rejection of the SCP'sconfiguration command. For instance, if the answering protocoldetermines that it is satisfied with its session configuration variablesand no configuration need occur, it can issue the rejection indicationto the SCP of the AT. No configuration occurs and control then ends withstep 530.

[0073] Alternatively, in step 535, if the answering protocol determinesthat configuration is necessary, the answering protocol returns theboolean value of true to the SCP of the AT, thereby communicating itsacceptance of the SCP's configuration command. The answering protocolnow prepares to communicate with its corresponding peer on the network.

[0074] The answering protocol maintains a timer which expires in aspecified amount of time if its corresponding peer in the network doesnot transmit a configuration response message within the specifiedamount of time. In one embodiment, this timer can be set to 2 seconds.One skilled in the art would recognize that this timer could be set forany amount of time useful for the present invention. The answeringprotocol also maintains a timer signal that indicates whether theconfiguration response timer is currently running. After the answeringprotocol accepts the configuration command transmitted to it from theSCP of the AT, it stops its timer and clears the timer signal.

[0075] After resetting the timer and clearing the signal, the answeringprotocol determines the desired value of the attribute that requiresconfiguration and stores this value into the “desired” variable (thatis, the variable containing the value that represents the change inreconfiguration of the current session).

[0076] In step 540, the answering protocol transmits a configurationrequest message to its corresponding peer on the network to instruct thenetwork to begin its part of the required configuration. In themeantime, the answering protocol records information about the attributebeing configured in the above-referenced regional structure (forexample, the attribute ID, transaction ID fields, and other flags areset). The answering protocol also maintains an awaiting acknowledgmentflag in the regional structure to determine if its request message wassuccessfully delivered to its corresponding peer in the network. Thisflag is initially set to true, indicating that the answering protocol isnow awaiting indication from it corresponding peer on the AN that itsconfiguration request message was successfully transmitted. In oneembodiment, a different regional structure would be created for eachconfiguration message to handle an answering protocol having multipledifferent configuration messages outstanding at one time. If delivery ofthe configuration request message from the answering protocol to itscorresponding peer in the network was unsuccessful, the configurationrequest message will be sent a specified number of times. The awaitingacknowledgment flag will continue to maintain its value of true,indicating that the answering protocol is still awaiting successfuldelivery of its configuration request message.

[0077] However, if the specified maximum number of times ofretransmission of the configuration request message is exceeded, theanswering protocol immediately returns a failed protocol negotiationindication. Included amongst this data is the attribute ID of theoffending attribute (that is, the attribute resulting in the failure).In another embodiment, the data would further include the transaction IDand any other data that would be useful for the SCP of the AT.

[0078] The answering protocol of the AT transmits the failed protocolnegotiation indication to the Session Management Protocol (SMP) of theAT. The current session is then closed. Finally, the SMP relays thefailed protocol negotiation data to the AN, thereby informing the ANthat the session was closed. This indication can contain theabove-referenced data received from the answering protocol.

[0079] If delivery of the configuration request message from theanswering protocol to its corresponding peer in the network wassuccessful, the above-referenced acknowledgment flag is set to falsebecause the answering protocol is no longer awaiting confirmation ofsuccessful delivery of its configuration request message. Theconfiguration response timer and signal are then set.

[0080] If the configuration response timer expires, the answeringprotocol transmits a failed protocol negotiation indication to theSession Management Protocol. The indication can include data associatedwith the failure (for example, the offending attribute ID). The currentsession is then closed. Finally, the SMP relays the failed protocolnegotiation indication to the AN, thereby informing the AN that thesession was closed. This indication can contain the above-referenceddata received from the answering protocol.

[0081] Thus, exceeding the maximum number of retransmission attemptsfrom the answering protocol to its peer and expiration of the timer areboth events that can cause unsuccessful configuration of the session.

[0082] In step 560, the answering protocol of the AT receives aconfiguration response message from its corresponding peer on thenetwork within the specified maximum amount of time (that is, before theabove-referenced timer expires). The waiting acknowledgment flag is nowset to false because the configuration request message had to have beensuccessfully delivered to the answering protocol's corresponding peer onthe network. Otherwise, the configuration response message would nothave been received by the answering protocol of the AT. Further, theconfiguration response timer is stopped because the answering protocolis no longer awaiting the configuration response message from itscorresponding peer on the AN. Similarly, the timer signal should becleared because the timer is no longer running.

[0083] The answering protocol then compares the ID of the configuredattribute (for example, the identification tag of the control channelattribute of the AT) in the configuration response message it receivedfrom its peer on the AN with the ID of the configured attribute that itmaintained in its regional structure before sending its configurationrequest message to its corresponding peer. This comparison is done toensure that the answering protocol's corresponding peer on the networkactually configured the attributes the answering protocol asked it toconfigure. In another embodiment, the returned ID contained in theresponse message is also compared to the value in the “desired” variableto ensure that the desired result was obtained. In yet anotherembodiment, other comparisons may also be made. The usefulness of suchcomparisons would be recognized by one skilled in the relevant art.

[0084] If the ID comparison results in a positive match, the answeringprotocol then stores the agreed-upon value of the configured attributeinto its negotiated variable and default variable.

[0085] In step 545, the answering protocol determines whether either ofthese events have occurred as described above.

[0086] If the answering protocol determines that configuration of thesession was unsuccessful, then in step 550, the answering protocoltransmits a failed protocol negotiation indication to the SMP of the AT.Control then ends with step 555.

[0087] Alternatively, if the answering protocol determines thatconfiguration of the session was successful, then control resumes inFIG. 5B with letter A.

[0088] In step 565, the answering protocol transmits a configurationcomplete indication to the SCP of the AT, thereby notifying the SCP thatit is done with its part of the configuration.

[0089] Alternatively, if the ID comparison (or other comparisons) doesnot result in a positive match, the answering protocol will return afailed protocol negotiation indication to the Session ManagementProtocol, including data related to the failure (for example, the ID ofthe offending attribute). Similar to the unsuccessful delivery of theconfiguration request message described above, an unsuccessfulcomparison results in the Session Management Protocol closing thecurrent session and sending the data received by the answering protocolto the AN.

[0090] In step 570, the answering protocol receives an indication fromthe SCP of the AT informing it that the required configuration has beencompleted. Thus, the value of the negotiated or previous variables arecopied to the current variable accordingly to reflect the newconfiguration.

[0091] In step 575, the answering protocol begins using the newconfiguration (for example, the control channel has been changed and theAT is currently utilizing this channel).

[0092] Finally, control ends with step 580.

[0093] Special Concerns

[0094] A. Losing a Traffic Channel

[0095] The IS-856 standard utilizes two communication channels, atraffic channel and a non-traffic channel. If there is no trafficchannel, data cannot be sent. The concern is that after theconfiguration request message is sent by any protocol of the AT, loss ofa traffic channel will occur and communication will be trapped in the ATinitiated state. The present invention addresses this concern andprevents entrapment in the AT initiated state.

[0096] First, the lower layers of the network (for example, the physicallayer) notify an Air Link Management Protocol (ALMP) (part of thecurrent IS-856 standard) that a traffic channel was lost. The ALMP thentransmits an indication to the SCP of the AT notifying it that thetraffic channel was lost. The SCP of the AT re-establishes theconnection and retransmits any configuration request messages for whicha configuration response message has not been received.

[0097] If the SCP of the AT has received a configuration responsemessage in response to all transmitted configuration request messages,the configuration complete message will be transmitted to the networkafter the lost traffic channel is reacquired. Alternatively, the SCP ofthe AT causes answering protocols to retransmit any configurationrequest messages through the configure command.

[0098] If a traffic channel was lost while one of the answeringprotocols was in the midst of configuration, the ALMP notifies the SCPof the AT that configuration was being by done by one of the answeringprotocols when the loss of a traffic channel occurred. Therefore, in oneembodiment, the SCP of the AT will immediately retransmit the configurecommands to all answering protocols of the AT. In another embodiment,the SCP of the AT maintains a list of protocols which accepted itsconfigure command but have yet to return a configuration completeindication. In this embodiment, the SCP of the AT only retransmits theconfigure command to the answering protocols which have not transmittedthe configuration complete indication to the SCP (due to the losttraffic channel).

[0099] In one embodiment each individual protocol remembers itsnegotiation state in order to resend its last outstanding message (thatis, the message that it would have transmitted to its peer in the ANbefore the traffic channel was lost. To determine separations betweenrounds of negotiations, the particular protocol can use the closedsession, previous session opened, and reconfigured indications todetermine the breaks between the various rounds of negotiations.

[0100] Eventually, one of the following events will occur:

[0101] (1) all answering protocols will complete their configuration,and communication will then proceed to an AN Initiated state;

[0102] (2) the session will close due to the time for awaiting aconfiguration response message in one of the protocol (either the SCPprotocol of the AT, or one of the answering protocols);

[0103] (3) the session will close due to the maximum number ofretransmission attempts for transmitting the configuration requestmessage; or

[0104] (4) the session will close due to a reacquiration after a fade,and a different network is acquired.

[0105] B. Losing Network Acquisition

[0106] As previously discussed, the present invention preventsentrapment in the AT initiated state during a lost traffic channel.Likewise, the present invention handles the situation in which networkacquisition is lost (that is, the entire network is lost). From theperspective of the SCP of the AT, this situation is handled as discussedabove for the situation in which a lost traffic channel occurs. However,before transmitting the configuration request message to the network,the SCP must first wait until a network is acquired. From theperspective of one of the answering protocols, the present inventionhandles this situation as described above for the lost traffic channelsituation.

[0107] It is anticipated that the features of the present invention areperformed and/or controlled by control processor 604, included incomputer system 600. Computer system 600 includes one or moreprocessors, such as processor 604. One or more processors 604 canexecute software and implement all or part of the features of thepresent invention described herein. Each processor 604 is connected to acommunication infrastructure 602 (for example, a communications bus,cross-bar, or network). After reading this description, it will becomeapparent to a person skilled in the relevant art how to implement theinvention using other computer systems and/or computer architectures.

[0108] Computer system 600 also includes a main memory 612, preferablyrandom access memory (RAM), and can also include secondary memory 614.Secondary memory 614 can include, for example, a hard disk drive 616and/or a removable storage drive 618, representing a floppy disk drive,a magnetic tape drive, an optical disk drive, et cetera. The removablestorage drive 618 reads from and/or writes to a removable storage unit620 in a well-known manner. Removable storage unit 620 represents afloppy disk, magnetic tape, optical disk, etc., which is read by andwritten to by removable storage drive 618. As will be appreciated by aperson skilled in the relevant art, the removable storage unit 620includes a computer usable storage medium having stored therein computersoftware and/or data.

[0109] In alternative embodiments, secondary memory 614 may includeother similar means for allowing computer programs or other instructionsto be loaded into computer system 600. Such means can include, forexample, a removable storage unit 624 and an interface 622. Examples caninclude a removable memory chip (such as an EPROM, or PROM) andassociated socket, and other removable storage units 624 and interfaces622 which allow software and data to be transferred from the removablestorage unit 624 to computer system 600.

[0110] Computer system 600 can also include a communications interface630. Communications interface 630 allows software and data to betransferred between computer system 600 and external devices viacommunications path 635. Examples of communications interface 630 caninclude a modem, a network interface (such as an Ethernet card), acommunications port, ecetera. Software and data transferred viacommunications interface 630 are in the form of signals which can beelectronic, electromagnetic, optical or other signals capable of beingreceived by communications interface 630, via communications path 635.Note that communications interface 630 provides a means by whichcomputer system 600 can interface to a network such as the Internet.

[0111] The present invention can be implemented using software running(that is, executing) in an environment similar to that described abovewith respect to FIG. 6. In this document, the term “computer programproduct” is used to generally refer to removable storage unit 620, ahard disk installed in hard disk drive 618, or a carrier wave or othersignal carrying software over a communication path 635 (wireless link orcable) to communications interface 630. A “computer useable medium” caninclude magnetic media, optical media, or other recordable media, ormedia that transmits a carrier wave. These computer program products aremeans for providing software to computer system 600.

[0112] Computer programs (also called computer control logic) are storedin main memory 612 and/or secondary memory 614. Computer programs canalso be received via communications interface 630. Such computerprograms, when executed, enable the computer system 600 to perform thefeatures of the present invention as discussed herein. In particular,the computer programs, when executed, enable the processor 604 toperform the features of the present invention. Accordingly, suchcomputer programs represent controllers of the computer system 600.

[0113] In an embodiment where the invention is implemented usingsoftware, the software may be stored in a computer program product andloaded into computer system 600 using removable storage drive 618, harddrive 616, or communications interface 630. Alternatively, the computerprogram product may be downloaded to computer system 600 overcommunications path 635. The control logic (software), when executed bythe one or more processors 604, causes the processor(s) 604 to performthe functions of the invention as described herein.

[0114] In another embodiment, the invention is implemented primarily infirmware and/or hardware using, for example, hardware components such asapplication specific integrated circuits (ASICs). Implementation of ahardware state machine so as to perform the functions described hereinwill be apparent to a person skilled in the relevant art.

[0115] Conclusion

[0116] While various embodiments of the invention have been describedabove, it should be understood that they have been presented by way ofexample, and not limitation. It will be apparent to persons skilled inthe relevant art that various changes in form and detail may be madetherein without departing from the spirit and scope of the invention.This is especially true in light of technology and terms within therelevant art(s) that may be later developed. Thus the invention shouldnot be limited by any of the above-described exemplary embodiments, butshould be defined only in accordance with the following claims and theirequivalents.

What is claimed is:
 1. A method for configuring, coordinating, andimplementing a plurality of protocol elements within an access terminalto allow the protocol elements to act in a cohesive manner to correctlyemulate an expected communication interface with a corresponding groupof protocols in a network protocol stack of a network, comprising thesteps of: (a) initializing a session configuration protocol; (b) readinga status of a current session from a non-volatile memory; (c) if saidsession configuration protocol determines during step (b) thatconfiguration data in said non-volatile memory is to be used, thenreading at least one session configuration variable from saidnon-volatile memory; (d) if said session configuration protocoldetermines during step (b) that there are no configuration variablesstored in said non-volatile memory, then assigning default values tosaid at least one session configuration variable; (e) initializing atleast one other protocol; and (f) sending a configuration command fromsaid session configuration protocol located within the access terminalto an answering protocol containing an attribute directly responsiblefor perfecting a need to change its existing status, said answeringprotocol also being located within the access terminal.
 2. The method ofclaim 1, further comprising the steps of: (g) if said answering protocoldetermines that configuration is necessary and accepts saidconfiguration command, communicating acceptance from said answeringprotocol to said session configuration protocol; and (h) if saidanswering protocol determines that no configuration is necessary andrejects said configuration command, terminating further processing. 3.The method of claim 2, further comprising the step of: (i) if saidanswering protocol accepts said configuration command, sending aconfiguration complete indication from said answering protocol to saidsession configuration protocol.
 4. The method of claim 3, furthercomprising the step of: (j) sending a message to the network uponreceiving a configuration complete indication from all protocols in theaccess terminal that accepted said configuration command.
 5. The methodof claim 3, wherein step (g) comprises the step of: (i) sending animmediate value of true from said answering protocol to said sessionconfiguration protocol upon acceptance of said configuration command. 6.The method of claim 3, wherein step (h) comprises the step of: (i)sending an immediate value of false from said answering protocol to saidsession configuration protocol upon rejection of said configurationcommand.
 7. The method of claim 5, wherein step (i) occurs through theuse of a boolean return value.
 8. The method of claim 3, furthercomprising the step of: (j) if said answering protocol accepted saidconfiguration command, sending a failed protocol negotiation indicationfrom said answering protocol to said session configuration protocol uponexpiration of a specified time period.
 9. The method of claim 3, furthercomprising the step of: (j) if said answering protocol accepted saidconfiguration command, sending a failed protocol negotiation indicationfrom said answering protocol to a session management protocol upondetermining that an attribute identified in a response message does notmatch an attribute identified in a request message.
 10. The method ofclaim 3, further comprising the step of: (j) if said answering protocolaccepted said configuration command, sending identification datacorresponding to an offending attribute from said answering protocol toa session management protocol.
 11. The method of claim 3, wherein step(f) occurs after first sending a configuration request message from saidsession configuration protocol to the network.
 12. The method of claim3, further comprising the step of: (j) if said answering protocolaccepted said configuration command, automatically sending a failedprotocol negotiation indication after a specified number of attempts toconfigure said session by said answering protocol.
 13. The method ofclaim 3, further comprising the steps of: (j)sending a configurationrequest message from said answering protocol in said access terminal toa corresponding peer in the network; and (k) receiving a configurationresponse message at said answering protocol in response to saidconfiguration request message transmitted from said answering protocol.14. The method of claim 13, further comprising the step of: (k) limitingthe time period between said receiving and sending steps.
 15. The methodof claim 3, further comprising the step of: (j) exiting an accessterminal initiation stage upon sending said configuration completemessage from said session configuration protocol to its correspondingpeer in the network.
 16. The method of claim 10, further comprising thestep of: (l) repeating said sending and receiving steps a plurality oftimes.
 17. A method for preventing entrapment within a sessionnegotiation in an access terminal, after detecting a lost trafficchannel on a network during an access terminal initiation state,comprising the steps of: (a) receiving an indication denoting that atraffic channel was lost, said indication being sent by a protocol groupat a connection layer in a protocol stack on said access terminal; (b)maintaining information regarding which answering protocols in theaccess terminal were in a process of communicating with the network; and(c) resending a configuration command from a session management protocolto said answering protocols that were in the process of communicatingwith said network.
 18. The method of claim 17, further comprising thesteps of: (d) sending an immediate value of true from said answeringprotocols if said answering protocols failed to communicate with saidnetwork due to said lost traffic channel; and (e) sending an immediatevalue of false from said answering protocols if said answering protocolssuccessfully communicated with said network despite said lost trafficchannel.
 19. The method of claim 18, wherein step (b) further comprisesmaintaining a list containing answering protocols that have responded toa session configuration protocol.
 20. The method of claim 18, furthercomprising the steps of: (f) transmitting a configuration completemessage from said session configuration protocol to said network upondetermining that all access terminal protocols have rejected aconfiguration command or completed configuration; and (g) receiving aconfiguration response message from the network after sending aconfiguration request message to the network.
 21. A method forreacquiring an interface connection between a network and an accessterminal, comprising the steps of: (a) maintaining data indicatingwhether current data transmittal is a first occurring data transmittalafter the interface connection was reacquired; (b) transmitting aconfiguration request message from a session configuration protocol to anetwork peer of said session configuration protocol on the network ifsaid data indicates that said current data transmittal is said firstoccurring data transmittal; and (c) preventing the access terminal fromwaiting on the network by allowing said access terminal to receive aconfiguration response message from said network peer of said sessionconfiguration protocol on the network.
 22. The method of claim 21,wherein step (a) comprises setting a boolean flag to true if saidcurrent data transmittal is said first occurring data transmittal afterthe interface connection was reacquired.
 23. The method of claim 21,wherein step (c) comprises maintaining a timer to track a time betweentransmitting said configuration command and receiving said completedconfiguration indication.
 24. The method of claim 21, wherein uponexpiration of a specified time, the access terminal returns to aninactive state.
 25. A method for configuring, coordinating, andimplementing a plurality of protocol elements within an access terminalto allow the protocol elements to act in a cohesive manner to correctlyemulate an expected communication interface with a corresponding groupof protocols in a network protocol stack, comprising the steps of: (a)transmitting a command to a protocol within the access terminal tothereby direct the access terminal to change from an open state to anaccess terminal initiated state; and (b) exiting said access terminalinitiated state upon receiving notice from all protocols within theaccess terminal.
 26. A computer program product comprising a computerusable medium having control logic stored therein for causing a computerto configure, coordinate, and implement a plurality of protocol elementswithin an access terminal to allow said protocol elements to act in acohesive manner to correctly emulate an expected communication interfacewith a corresponding group of protocols in a network protocol stack,said computer program logic comprising: a first computer readableprogram code means for causing the computer to detect a need to changean existing condition in the access terminal; a second computer readableprogram code means for addressing said need by sending a configurationcommand from a session configuration protocol located within the accessterminal, said configuration command being sent to an answering protocolcontaining an attribute directly responsible for perfecting said change,said answering protocol being located within the access terminal; athird computer readable program code means for determining if saidanswering protocol accepts or rejects said change; a fourth computerreadable program means for sending an immediate value of true from saidanswering protocol and sending a future indication from said answeringprotocol, said value being sent if said answering protocol accepted saidchange, said indication comprising one of a failed protocol negotiationindication and a configuration complete indication; and a fifth computerreadable program means for sending a value of false from said answeringprotocol and terminating further processing if said answering protocolrejects said change.
 27. An access terminal, in which configuration andcoordination of a plurality of protocols occurs to allow said protocolsto act in a cohesive manner to correctly emulate an expectedcommunication interface with a corresponding group of protocols in anetwork protocol stack, comprising: means for causing the computer todetect a need to change an existing condition in the access terminal;means for addressing said need by sending a configuration command from asession configuration protocol located within the access terminal, saidconfiguration command being sent to an answering protocol containing anattribute directly responsible for perfecting said change, saidanswering protocol being located within the access terminal; and meansfor determining if said answering protocol accepts or rejects saidchange.
 28. The access terminal of claim 27, further comprising: meansfor sending a failed protocol negotiation indication from said answeringprotocol to said session configuration protocol of the access terminal.29. The access terminal of claim 28, further comprising: means forsending a configuration complete indication from said answering protocolto said session configuration protocol of the access terminal.